1. Technical Field
The present invention relates generally to methods and systems for automating the dissemination of enterprise policies to all policy-based components in an enterprise management infrastructure, derivation of component specific policies from global policies, and customization of resource arbitration among computing services based in objectives defined by the enterprise policies.
2. Description of the Related Art
An enterprise computing infrastructure, like that of a service-provider business, provides multiple computing services. These services are implemented by one or more service components, and the service components are managed by one or more information technology (IT) management components based on specific policies. For example, a service may be composed of multiple components running in a three-tier environment, i.e., web serving, application logic execution, and database access. The IT management components for managing these tiers may include workload management in an application server and database, resource allocation and provisioning for these tiers, etc. These IT management components, referred to herein as policy-based components, use multiple types of policies, including configuration rules, procedural (action) rules, and service level objectives.
A configuration rule defines the values of specific service parameters. Procedural rules define the procedure that the service should execute in response to specific events or situations. A service level objective refers to the quality of the provided service, and comprises a service level goal, a (time) qualifying condition, and expressions for one or more business value models (e.g., importance, penalty, reward, and utility) for meeting these service level objectives.
FIG. 1 shows a prior art system which includes manually setting of policies to multiple policy-based components that manage the same set of services or service components. More specifically, in an overall system with multiple policy-based components 4 (e.g., 4a-4c), a set of services 9, running on top of a set of enterprise resources 10, are managed by these policy-based components 4. The policies to be used by these policy-based components 11 (e.g., 11a-11c) are manually set by one or more administrators 12, using graphical user interfaces (GUIs) 16 (e.g., consoles) or administration script 14.
The administrators 12 learn and interpret the enterprise business goals, and manually define component policies. For example, as described in the web article “Autonomic features of the IBM Virtualization Engine”, by Lori Simcox, published at the IBM website for the IBM Enterprise Workload Manager, the deployment of specific policy is done through the EWLM Control Center web-based console or through a Java-based programmatic interface. Similarly, for the IBM WebSphere Extended Deployment, the specification of service policy is done through the administrative console, as described in web article “Architecting on demand solutions, part 6: Optimize your on demand applications and resources using IBM WebSphere Extended Deployment 5.1, by Wilfred Jamison and Ann Black-Ziegelbein and published at the IBM website, or through wsadmin scripts.
In Internet RFC archives, RFC 2748 specifies Common Open Policy Service Protocol in a policy management framework, where the Policy Enforcement Point (PEP) clients receive policy information from a Policy Decision Point (PDP) server in the same administrative domain. A PEP “sends requests, updates, and deletes to the remote PDP and the PDP returns decisions back to the PEP”. The server maintains the state of prior communication, and based on the identity of PEP, sends appropriate responses.
There are many different languages for specifying policies. Web Services Agreement (WS-Agreement) specification, being defined in Global Grid Forum, published in “Web Services Agreement Specification (WS-Agreement)” by the Grid Resource Allocation Agreement Prototcol WG uses four tuples in describing service level objective policies, as part of guarantee term definition.
Referring to FIG. 2, four components of a WS-Agreement policy are illustrated. The Scope component 301 of a policy defines service elements for which service level objectives are defined. The Qualifying Condition component 304 defines external conditions, such as time of the day, which must be met for a service level objective policy to be enforced. The Service Level Objective component 302 defines a condition expressing a service level to be enforced. Typically, this is expressed as a target associated with a Key Performance Indicator or KPI. Finally, the Business Value component, 303, defines value assertions by service clients or providers in meeting a service level objective. There are many business value models in defining value assertions. For example, priority can be used to prioritize one objective over other objectives. Under resource constraints, resources are allocated to meet objectives in terms of priority order. For a higher priority objective, once the KPI threshold is met, further improvement in service level is not required, and remaining resources should be allocated to meet the next set of objectives in terms of priority order.
Business value can also be expressed by both clients and providers in terms of a penalty function, where penalty (or reward) is expressed as a function of deviation from the KPI threshold. Yet, in another model, Business Value can be expressed as a preference of different service states in quantitative terms.
During runtime, multiple management components may interact with one another according to the policies governing their interactions. FIG. 3 illustrates a typical prior-art scenario for resource orchestration in an enterprise computing scenario, similar to the one presented in U.S. Patent Application 20030149685, “Method and System for Managing Resources in a Data Center”. More specifically, in a system with multiple objective-based components 204 that manage a set of services 202 based on a set of specific objectives, on top of a set of enterprise resources 205, the resource arbitration among objective managers is performed by a resource arbiter 200. An arbiter's decision results in a provisioning plan 206, which is executed by a Resource Provisioner 207, by applying the related provisioning operations 208 on the related resources 205.
Administrators setup the specific objective policy for each of the objective managers and define the fixed service priorities, 213, based on which the arbiter makes the resource arbitration decisions. In the process of the arbitration decisions, the arbiter receives objective status information 209 from the objective manager and uses this information, along with the service priority 213 as input for its optimization method 211.
This approach is not appropriate when the business values of enterprise objectives depend on service performance parameters, such as a penalty value that depends on the amount of transactions that do exhibit a response time larger than the objective cannot be expressed by a fixed, predefined number. In contrast, this type of business value must be specified as a function that is evaluated at runtime based on the observed or predicted service Key Performance Indicators (KPIs).
Other proposals, including the “Utility Functions in Autonomic Systems”, by W. Walsh, G. Tesauro, J. Kephart, R. Das, published in International Conference on Autonomic Computing, 2004, assume that the business-value model is encapsulated in the objective manager, which can provide on request the value associated with service levels achieved on a given resource allocation. This approach limits the ability of the enterprise to evolve its business model independently of the implementation of the objective managers in its IT infrastructure. For instance, in order to change the business value model from a priority-based service to a penalty-based service, the objective manager components handling only the priority model have to be extended with functionality for computing the penalty expression based on the appropriate service parameters.
In prior-art proposals, the arbitration method is designed to use fixed business value models, e.g., a fixed set of business value components, like importance, or penalty and reward. However, objectives originating from different sources and destined to different services can have different business value model components, e.g., some have only importance, while others have both importance and penalty. Depending on the mix of services subject to arbitration at a given moment in time, enterprise service objectives can indicate what type of business models to be used in arbitration, possibly indicating that more than one type to be used. For example, for one group of resources, the decision is based on the importance model, while for other group of resources, the decision is based on penalty and reward. As a consequence, the optimization method used by the arbiter changes along with the type of business value models.
With the prior art, the orchestration decisions are always based only on that particular set of business value models that are known to be defined for all service objectives at any time, such as importance. This approach prevents the enterprise from always applying the orchestration objectives that best fit its business model. For example, at times when the actual common business value model includes both importance and penalty versus only penalty, the enterprise objective is to minimize penalty, yet ensure that the higher importance objectives are given priority. In this case, a decision that ignores importance and minimizes penalty overall, might affect higher importance objectives to the benefit of lower importance objectives with lower penalty.
Prior-art proposals, including “FARA—A Framework for Adaptive Resource Allocation in Complex Real-Time Systems”, by D. Rosu, K. Schwan, S. Yalamanchili, published in the IEEE Real-Time and Embedded Technology And Applications Symposium”, 1998, have considered the runtime customization of the arbitration method based on the type of violated service objectives, but it uses a fixed value model.